There are two types of chat models. The first type is a peer-to-peer chat model (such as, for example, IBM SameTime). Chat applications operating in accordance with this model have a peer “Presence” information display that a user clicks to chat. The second type is a help desk services chat model. In the second type of chat model there is no peer presence information available; the user just clicks a button asking for help and the chat system automatically routes the request to an available chat agent.
Chat has become increasingly important as an effective means for contacting a help desk. Cultural shifts and increased use of text messaging and instant messaging have resulted in using these methods to contact a help desk agent. The current model of help desk chat is a charge-free model, such that everyone is allowed to access a chat resource to contact a help desk agent. It is the responsibility of the help desk agent to verify and filter the legality of the user. This negatively impacts help desk agent productivity and increases the cost of providing help desk services.
It has also been found that the average help desk agent can handle only 1 voice call at a time, but can handle 2-5 chat sessions simultaneously. Accordingly, the savings associated with providing chat as an alternate method for contacting a help desk can be significant.
Existing help desk chat products consist of three components: (1) a routing engine; (2) an agent application/graphical user interface; and (3) an API for a customized user facing application/graphical user interface. Conventional chat systems configured accordance with the prior art have several drawbacks. These drawbacks will be discussed in the following paragraphs.
Conventional chat systems do not provide a secure and scalable model to validate a chat session. Certain voice call help desk implementations require a user to key in a password before the call can reach an agent. However, such voice call user verification mechanisms cannot be applied effectively to chat systems. Voice call system user verification is a “once only” check. The voice system answers the user's call and verifies the user's password, and then redirects the call to the agent, after that the verification system is “out of the loop”. This method works only for voice systems since there is no other way for a user to access the help desk resource (agent). This method does not work for chat system service since the chat system comprises an internet resource and resources associated with the chat system (such as, for example, chat routing infrastructure and agents) can be accessed by URL. Such accessibility creates significant security issues.
Some existing chat products do provide a local database internally for user authentication. This approach is not scalable since enterprise users have their own LDAP for user authentication. It would require a large effort for the service provider to duplicate and synchronize the LDAP to the local database for each enterprise customer.
Conventional chat systems also require that user facing chat applications be implemented and run in the same machines as the existing chat product. This imposes a very severe limitation since the owner of the chat resource and chat applications may be different. Conventional architectures of chat systems do not support installation of a firewall that would prevent users from directly accessing the chat resource.
Conventional chat systems also require language-specific infrastructure to support various languages. In chat systems operating in accordance with the prior art a language-specific system is implemented to support a single language. This language-specific system can be a language-specific API component for chat applications to use. It is very expensive for a service provider to implement a universal chat service that supports all the languages in the world.
Conventional chat systems only support text chat. Conventional chat systems do not support multimedia. There are technical difficulties in supporting multimedia chat due to conflicting critical requirements specific to providing a chat service tool for a help desk. One critical requirement is that the tool needs to provide an API for service providers to write their own user facing chat application. The user facing chat application must also provide a path for service providers to integrate the chat application with external enterprise applications. This “customized” user facing chat application requirement results in the user facing and the agent facing applications not being able to talk to each other directly. These two components need to communicate with each other via a transport pipe of the existing chat product. Since there is no standard way to transport multimedia content in chat, the existing products cannot support multimedia chat for help desk services.
Conventional chat systems do not automatically integrate with ticketing systems. It is an important requirement that there be a ticket created for each chat contact of the help desk. Usually, the ticket is created manually by the agents performing the service. The agent will fill in the context of the conversation in the ticket after the session. This is time-consuming and negatively impacts the productivity of the chat agent.
Conventional chat systems do not support embedded commands. Once a chat session has been established, communication between user and agent is only of the chat content, no embedded commands are allowed.
Accordingly, those skilled in the art seek improved chat systems that overcome each of the foregoing limitations and drawbacks of the prior art.